ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group99a.txt/000085_icon-group-sender _Mon Apr 5 13:20:34 1999.msg

Internet Message Format | 2000-09-20 | 6KB

Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA02010
    for icon-group-addresses; Mon, 5 Apr 1999 13:20:09 -0700 (MST)
Message-Id: <[e-mail]>
From: "Mark Evans" <[e-mail]>
To: "Icon List" <[e-mail]>
Subject: RE: Ccon and Icon-based Compilers
Date: Mon, 5 Apr 1999 11:52:15 -0500
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Errors-To: [e-mail]
Status: RO

Thanks, Todd!  Helpful comments.

Garbage collection is not a big deal to me, e.g.
http://reality.sgi.com/boehm_mti/gc.html

As for runtime support, it already exists in C.  The Icon interpreter is
implemented in C.  All I have to do is tweak the code that is there already.
(With Jcon, you did not have Java code for the runtime system; your case is not
the same as mine.)

I like co-expressions but detest their current implementation, which involves
custom assembly language.  Yuk!  I want to rewrite that stuff, whether with
threads or something simpler.

Type inferencing is fine if it helps performance, and if there is code already
out there.  Presumably I can get my hands on the source to "iconc" and determine
how it was done.

We can talk ourselves blue in the face about whether C will perform better than
native Icon.  To me that is not the point.  The point is, I want to extend the C
language.  I want Icon code that integrates cleanly into C/C++ projects under
Windows.  The reason I said that I wanted to avoid discussion of "why C?" is
that I already know my reasons, and they are valid.

Best regards,

Mark



-----Original Message-----
From: Todd Proebsting [mailto:[e-mail]]
Sent: Monday, April 05, 1999 11:24 AM
To: 'Mark Evans'; Icon List
Subject: RE: Ccon and Icon-based Compilers


Jcon's translator is written in Icon.  It would be very easy to adapt it to
emit C++ (or assembly for your favorite machine).  In fact, the translator
was structured to be easy to retarget.  (I'm toying with the idea of
retargetting Jcon to emit Postscript---with only a limited run-time
system---just for kicks....)

The problem is not translating Icon, however, but providing the run-time
support for all of Icon's built-in types and functions.  This can be done
easily in C++, too, with enough time.  With the exception of the graphics
stuff, most of Jcon should translate pretty cleanly into C++.

Two issues that any Icon implementation must face are how to handle
co-expressions, and how to handle garbage collection.  Co-expressions are
easy if you have a threads package.  Garbage collection is a royal pain.
Jcon relied on Java's garbage collection, so GC in Jcon was free.  Unless
you use a conservative collector in a C++ implementation, I think GC would
be complete mess: a source of lots of complications, lots of performance
problems, and lots of hard-to-track bugs.

I should comment, however, on emitting machine code.  It's not going to help
performance much at all.  The vast majority of the time in an Icon program
is spent in the run-time system, not in compiled code.  In Jcon, its around
10% in compiled code, if I recall correctly.  (The old Icon compiler, iconc,
had significant performance gains not because it compiled to C rather than
being interpreted, but because it did type inferencing to avoid having to do
lots of type conversions and type tests.  This is an orthogonal issue to
what target or implementation languages are used.)

I'd be surprised if any implementation of Icon is going to be significantly
faster than the current interpreter unless the new implementation does
type-specific optimizations.

Todd

-----Original Message-----
From: Mark Evans [mailto:[e-mail]]
Sent: Saturday, April 03, 1999 8:35 AM
To: Icon List
Subject: Ccon and Icon-based Compilers



The Jcon effort involved a Java translator plus a runtime system in Java.
My
question is whether anyone has ideas about the same concept for the C/C++
language.  Let's call it "Ccon."  That is, a runtime system
(library/classes),
plus a translator to turn Icon into C/C++ targeted for that runtime system.

I remember something called "iconc" but it seems to have fallen into
disfavor,
is not being upgraded, all attention is now on Unicon, etc., etc.

Another idea for which I would like to solicit opinions is writing a
machine-code compiler in the Icon language directly.  Good?  Bad?  Ugly?
What
about using a GNU compiler and then Icon code as the front end and/or back
end.
Any advantages?

The kind of comments I don't need are people telling me that I don't need C
code, I can use Icon as it is, why don't I get with it, etc.  If I didn't
need C
code I wouldn't bother with this note.

Regards,

Mark Evans




Believe Evolution?  Save this block as FAITH.HTM and open with your browser.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<HTML><HEAD></HEAD><script language="JavaScript">function doFaithJump(){
site =
"http://www." + document.FF01.FL01.value; W = open(site)}</script><FORM NAME
=
"FF01"><P><SELECT NAME="FL01"><OPTION SELECTED
VALUE="netgoal.com/lacf.nsf/general/debate+highlights">Los Alamos Origins
Debate<OPTION VALUE="parentcompany.com/handy_dandy/hder3.htm">Evolution
Refuter<OPTION VALUE="christiananswers.net/creation/home.html">Christian
Answers<OPTION VALUE="gospelcom.net/rbc/rtb/8rsn/">Ten Reasons<OPTION
VALUE="xenos.org/classes/papers/doubt.htm">Still Doubtful?<OPTION
VALUE="apologeticsinfo.org/bibliographies/jesusresurrection.html">Read All
About
It<OPTION VALUE="persecutedchurch.org/home.htm">The Price is Still
Blood</SELECT><INPUT TYPE="button" NAME="Go" VALUE="Go"
onClick="doFaithJump()"></P></FORM></BODY></HTML>